home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000553_fine@cis.ohio-state.edu _Tue Jan 12 23:36:39 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Return-Path: <fine@cis.ohio-state.edu>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA27044; Tue, 12 Jan 93 23:36:39 MET
  4. Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA13287; Tue, 12 Jan 1993 23:51:47 +0100
  6. Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
  7.     id AA13895; Tue, 12 Jan 93 17:51:29 -0500
  8. Date: Tue, 12 Jan 93 17:51:29 -0500
  9. From: Thomas A. Fine <fine@cis.ohio-state.edu>
  10. Message-Id: <9301122251.AA13895@soccer.cis.ohio-state.edu>
  11. To: connolly@pixel.convex.com, @cis.ohio-state.edu@cis.ohio-state.edu
  12. Subject: Re: HTML todo list 
  13. Cc: timbl@nxoc01.cern.ch, www-talk@nxoc01.cern.ch
  14. X-Mailer: Perl Mail System v1.1
  15.  
  16. >>I don't think we should do any shortref magic.  The simplest thing
  17. >>(the way it works now) is that the two examples above are identical.
  18. >>I say this is fine.
  19. >
  20. >But it's a royal pain to implement! Doing full SGML newline processing
  21. >by the standard is quite involved (see the article by Eric Naggum
  22. >in comp.text.sgml about SGML and Records that I referenced in
  23. >an earlier message). For example, you can't just get rid of all
  24. >newlines immediately before or after tags, like it says in the
  25. >web: Only those right after a start tag (of a non-empty element),
  26. >right before an end tag,
  27. >or the ones on a line containing only comments and processing instructions.
  28. >Newlines around <P> tags, for example, _are_ reported.
  29. >
  30. >If we don't stick the SHORTREF magic in the DTD to force the
  31. >parser to report all newlines, we'll end up with countless hacks
  32. >at newline processing, none of which matches the standard, and
  33. >it'll be luck if any of them matches each other.
  34.  
  35. Not necessarily.  Carefully define which new-lines have to be ignored.
  36. This may yield something complex.  But then, you are still free to ignore
  37. more new-lines than that in several different places, thus reducing the
  38. problem.  In other words, it is up to the formatting program to decide
  39. how to interpret them.  If it decides to throw out a few more new-lines
  40. at the beginning or end of various data elements, life becomes much
  41. easier.
  42.  
  43. You might have countless hacks, but since formatters ar allowed to
  44. format things differently, does it matter?
  45.  
  46. Take this example:
  47.  
  48.   Here's some text<P>And some more text
  49.   <P>
  50.   And some final text.
  51.  
  52. SGML may say this:
  53.  
  54.   \nHere's some text
  55.   (P
  56.   )P
  57.   And some more text\n
  58.   (P
  59.   )P
  60.   \nAnd some final text.
  61.  
  62. But the formatter is still free to toss those new-lines at the beginning
  63. and end of each paragraph (and in fact it had better if you don't want
  64. a space at the beginning of your paragraphs).
  65.  
  66.      tom